The requirement to cater for mobility in packet data communication systems, for example IP-systems (Internet Protocol systems), is widely recognized and the research and development activities in the area are extensive. Different aspects of mobility, which a packet data communication system preferably may manage, may be envisaged. A first example relates to a mobile communication node moving and therefore need to change its access point to the fixed network from a first access point of a first Wireless Local Area Network (WLAN) to a second access point of a second WLAN. A second example of mobility involves not just a moving communication node, but also a whole network which is moving. The mobile communication node may be fixed relative the moving network, or alternatively, is in relative motion also with regards to the moving network. An examples of a moving network is a local network within a transport vehicle (e.g. bus, train or aircrafts), which will include a mobile router or mobile routers through which all communication nodes in the moving network can communicate. The moving network will typically comprise communication nodes, including user equipment (UE) with communication abilities, such as laptops, mobile phones, PDAs (Personal Digital Assistants), game pads etc. Also equipment not associated to a human user such as vending machines, ATMs, the transport vehicle itself and other types of machinery may be provided with communication means and part of the moving network. The communication nodes communicate via wireless or wireline means with a router (or more) within the transport vehicle, such that all communication destined to an external address will pass via the router. A moving network may also be e.g. a Personal Area Network (PAN), wherein a PAN comprises all communication devices associated with a user and situated within short range radio communication distance form each other.
Various aspects of mobility in IP-based communication systems are regulated in the Mobile IPv6 (MIPv6) protocol. Moving networks is in IPv6 referred to as NEtwork MObility (NEMO) and described in “The Network Mobility (NEMO) Basic Support Protocol”, by Devarapalli et al, RFC 3963, January 2005. The protocol is an extension of Mobile IPv6 and allows session continuity for every communication node (or communication device) in the moving network as the network moves. It allows a mobile router (MR) to maintain a stable network prefix for a moving network, the Mobile Network Prefix, MNP, even as the mobile router changes its, and thus the moving network's, point of attachment to a fixed network infrastructure. The Mobile Network Prefix will in the following be refereed to as the prefix.
The prefix stability is achieved by making a Home Agent (HA) a fixed point of presence, for the MR and maintaining connectivity between the HA and the MR through a bi-directional tunnel, which is similar to the handling of a moving communication node according to Mobile IPv6. The prefix is allocated from an address range of the home network, i.e. the subnet to which the HA is attached, and can thus remain the same even as the MR and its network moves. When the MR attaches to a network in a new location, it acquires a new care-of address, but the MRs home address and prefix are unchanged. However, in similarity with MIPv6 the MR has to register its new care-of address in the HA in order to maintain the MR-HA tunnel as described in D. Johnson et al., “Mobility Support in IPv6”, RFC 3775, June 2004.
The communication nodes belonging to the moving network that moves along with the mobile router (or routers) are called Mobile Network Nodes (MNNs). According to the NEMO basic support protocol their configuration will not be changed as the MR changes its point of attachment. In other words, the mobility is transparent to them.
The prior art NEMO basic support protocol allows only a single care-of address to be registered in the HA for a certain MR at any one time. Multiple simultaneous care-of addresses are not allowed and thus multiple simultaneous accesses and MR-HA tunnels are not possible for a MR.
Furthermore, the NEMO basic support protocol assumes that the MR is preconfigured with the prefix that is allocated to the MR out of the address range of the home network (or other prefix range supported by the HA).
As an option in the NEMO basic support protocol, the MR and the HA uses a regular routing protocol on its mutual “link”, i.e. in between each other in the MR-HA tunnel. With this option the HA is not provided with the ability to handle announcement of prefixes that are being used by “active” MRs (i.e. MRs that have valid bindings in the HA). This is instead handled automatically by the routing protocol in the regular manner.
Multiple MRs may be advantageous in that they provide several external accesses to the moving network, possibly using several different access technologies. There are several reasons motivating why support for simultaneous usage of several accesses is beneficial in this scenario, including e.g. robustness, increased aggregated bandwidth and different application/user requirements/preferences. In order to provide an efficient and correct synchronization of source address selection and router selection, the MRs belonging to the same moving network, and sharing the same HA, should preferably be assigned the same prefix. Although Mobile IPv6 and the NEMO basic support protocol do not prevent MRs sharing the same prefix, there is no explicitly support for this either. This lack of support may give rise to an uncontrolled prefix-situation with potential problems of inconsistent routing tables and malfunctioning routing.
The Internet-Draft “Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks” [http://ietfreport.isoc.org/all-ids/draft-cho-nemo-mr-registration-00.txt] 2004, describes a method wherein a MR identifies neighboring MRs in the same moving network, that can be used to provide alternative paths for fault recovery and/or load sharing. According to the described method, router advertisements are extended with addressing information, the home address (HoA) and care-of address (CoA), of the sending MR. A MR gathers information about its neighboring MRs by listening to router advertisements and collecting the addressing information associated with each identified neighbor MR. The retrieved addressing information is “authenticated” through the return routability test according to Mobile IPv6. However, since the basis for the “authentication” is information originating from the neighboring MR itself, the security will be low. The system will for example be vulnerable to attacks. An attacker could first find out CoA and HoA of another MR (which may be located anywhere) and then announce these parameters in a false router advertisement. Listening MRs would not be able to detect that the information is false, since the return routability test would succeed. Thus, the neighbor MRs as well as their respective HAs would be fooled by the attacker.
The Internet-Draft “Token based Duplicate Network Detection for split mobile network (Token based DND)” by M. Kumazawa et al., [http://ietfreport.isoc.org/all-ids/draft-kumazawa-nemo-tbdnd-02.txt], 2005, describes a solution that has as one of its purposes to allow the HA to verify that a MR requesting to be assigned a certain prefix that is already being used by (and “owned” by) another MR is connected to the same moving network as the other MR (i.e. the prefix “owner”).
The solution is based on a token that is associated with a prefix. The MR that “owns” the prefix generates the token and sends it to the HA in the Binding Update message (BU) and then includes it in its Router Advertisements. If another MR subsequently sends a BU with the same prefix in the Mobile Network Prefix option it has to include the token associated with the prefix (assumedly received in a Router Advertisement from the “owner” of the prefix). The HA compares the prefix and token with the ones it has previously stored and if they match, the MR is accepted as a “borrower” of the prefix. If the MR fails to supply this token or supplies another token, the HA will not accept the MR as a “borrower” of the prefix.
A serious drawback of this solution is that that no protection is offered against a malicious MNN or MR that hi-jacks the token and pretends to be the owner of the prefix.
Further drawbacks originate from the facts that the solution distinguishes between “owners” and “borrowers” of a prefix and that the token is associated with a prefix, not an MR. This asymmetry makes the solution inflexible. For instance, a MR cannot use a certain prefix unless its (preconfigured) “owner” is already actively using it and if the “owner” of the prefix is disconnected, and its binding in the HA times out, then any other MRs using the prefix have to abandon it. A further problem is that the mechanism only verifies that the “owner” of a certain prefix is connected to the same moving network, but disregards existing “borrowers” of the prefix. Furthermore, the mechanism has poor temporal properties as the token update period, is the same as, or greater than, the Binding Update period, which further contribute to the severe security issues of the token-solution.